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REMARKS 

This is a full and timely response to the outstanding non-final Office Action mailed 
August 11, 2008 (Paper No. 20080802). Upon entry of this response, claims 1-28 are pending in 
the application. Applicant respectfully requests reconsideration of all pending claims. 



I. Rejection of Claims 6-7 and 13-14 under 35 U.S.C. 5102 

Claims 6-7 and 13-14 are rejected under §1 02(e) as allegedly anticipated by Athreya et 
al. (U.S. 7,222,348). Applicant respectfully traverses this rejection. A proper rejection of a claim 
under 35 U.S.C. §102 requires that a single prior art reference disclose each element of the 
claim. See, e.g., W.L Gore & Assoc., Inc. v. Gariock, Inc., 721 F.2d 1540, 220 U.S.P.Q. 303, 
313 (Fed. Cir. 1983). 



A. Independent Claim 6 

The Office Action contends that Athreya et al. teaches all the features of claim 6 as 

follows: 

determining a uni-role first driver registered to the device [device objects 
correspond to physical devices having M device types; col. 2, lines 20 - 
30]; 

invoking the first driver, which includes passing the PDO of the device to 
the first driver [filter add device function 450 creates and initializes a new 
filter device object for the corresponding physical device object; col. 7, 
lines 8 - 25]; and 

passing the PDO from the first driver to the multi-role second driver or to 
a component of the kernel [driver entry 410 provides an entry point for the 
UMD 220 in response to an IRP issued by the higher level driver 218; col. 
6, lines 60 - 67]. 
(Office Action, p. 3.) 

Applicant respectfully disagrees. Applicant first notes that Athreya et al. does not discuss device 
driver registration at all, and thus does not disclose "determining a uni-role first driver 
registered to the device" as recited in claim 6. Since Athreya et al. does not teach all of the 
features of claim 6, the rejection should be withdrawn. 
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Applicant next notes that the cited sections of Athreya et al. refer to two different drivers, 
a universal multipath driver (UMD) and a lower-level driver. The Office Action does not clearly 
explain which of the two types of drivers in Athreya et al. corresponds to the claimed "uni-role 
driver" and which corresponds to the claimed "multi-role second driver". Applicant will therefore 
address two alternative interpretations of the rejection, and discuss why Athreya et al. does not 
disclose, teach, or suggest "passing the PDO from the first driver to the multi-role second driver 
or to a component of the kernel" as recited in claim 6, under either interpretation of the Office 
Action rejection. 

Applicant first assumes that the universal multipath driver of Athreya et al. corresponds 
to the claimed "multi-role driver", and that the lower-level driver corresponds to the claimed "uni- 
role driver". The Office Action relies on Athreya et al. Col. 7, lines 8-25 in the rejection, a section 
which describes various entry points to the universal multipath driver. This section appears to 
teach that calling the filter add device function entry point 250 in the universal multipath driver 
would in turn invoke the lower-level driver (allegedly "invoking the first driver"). However, 
Athreya et al. does not disclose, teach, or suggest "passing the PDO" from the lower-level 
driver back to the calling multipath driver (allegedly "passing the PDO from the first driver to the 
multi-role second driver") as explained below. 

This feature is not taught by the section of Athreya et al. discussed above (Col. 7, lines 
8-25), since this section is silent on what the lower-level driver does with device objects after 
invocation from the filter add device function. The Office Action (p. 3) relies on a different 
passage in Athreya et al. to reject the "passing the PDO" feature: "driver entry 410 provides an 
entry point for the UMD 220 in response to an IRP issued by the higher level driver 218 (Col. 6, 
lines 60-67)". However, this second passage discusses the universal multipath driver rather 
than the lower-level driver, and thus cannot properly teach "passing the PDO from the uni-role 
driver" under the construction assumed in this paragraph. Nor does Athreya et al. disclose, 
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teach, or suggest "passing the PDO" from the lower-level driver (the alleged "uni-role driver") to 

"a component of the kernel" as recited in claim 6. 

Alternatively, Applicant assumes that the lower-level driver of Athreya et al. corresponds 
to the claimed "multi-role driver", and that the universal multipath driver corresponds to the 
claimed "uni-role driver". The Office Action (p. 3) relies on Athreya et al. Col. 7, lines 8-25 in the 
rejection, which describes various entry points to the universal multipath driver. This section 
refers to a filter add device function entry point 250 in the universal multipath driver (allegedly 
"invoking the uni-role driver"), and Applicant assumes that "the PDO" is passed when calling this 
entry point. However, Athreya et al. does not disclose, teach, or suggest "passing the PDO" 
from the universal multipath driver to the lower-level driver (allegedly "passing the PDO from the 
first driver to the multi-role second driver or to a component of the kernel.") as recited in claim 6. 
In fact, Athreya et al. specifically states that the filter add device function in the universal 
multipath driver passes a "new filter device object" rather than passing the physical device 
object (PDO) associated with the uni-role driver. (A specific physical device object is associated 
with the uni-role driver through the registration of the uni-role driver for the device.) Nor does 
Athreya et al. disclose, teach, or suggest "passing the PDO" from the multipath driver (the 
alleged "uni-role driver") to "a component of the kernel" as recited in claim 6. 

For at least the reason that Athreya et al. fails to disclose, teach or suggest the above- 
described features, Applicant respectfully submits that Athreya et al. does not anticipate claim 6. 
Therefore, Applicant requests that the rejection of claim 6 be withdrawn. 

B. Independent Claim 7 

The Office Action contends that Athreya et al. teaches all the features of claim 7 as 

follows: 

determining a driver registered to the device [device objects correspond 
to physical devices having M device types; col. 2, lines 20 - 30]; 
invoking the driver, which includes passing the PDO of the device to the 
driver [filter add device function 450 creates and initializes a new filter 
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device object for the corresponding physical device object; col. 7, lines 8 
- 25]; and 

passing the PDO away from the driver without attempting to attach to the 
stack a DO corresponding to the driver [driver entry 410 provides an entry 
point for the UMD 220 in response to an IRP issued by the higher level 
driver 218; col. 6, lines 60 - 67]. 
(Office Action, p. 4.) 

Applicant respectfully disagrees, and first notes that the Office Action has used exactly the 
same portions of Athreya etal. in rejecting claim 7 that were used to reject claim 6, even though 
these claims are clearly not equivalent in scope. Next, Applicant notes that Athreya et al. does 
not discuss device driver registration at all, and thus does not disclose "determining a driver 
registered to the device" as recited in claim 7. Since Athreya et al. does not teach all of the 
features of claim 7, the rejection should be withdrawn. 

Applicant next notes that the cited sections of Athreya et al. refer to two different drivers, 
a universal multipath driver (UMD) and a lower-level driver. The Office Action does not clearly 
explain which of the two types of drivers in Athreya et al. corresponds to the claimed "driver". 
Appicant will therefore address two alternative interpretations of the rejection, and discuss why 
Athreya et al. does not disclose, teach, or suggest "passing the PDO away from the driver 
without attempting to attach to the stack a DO corresponding to the driver" as recited in claim 7, 
under either interpretation of the Office Action rejection. 

Applicant first assumes that the universal multipath driver of Athreya et al. corresponds 
to the claimed "driver". The Office Action (p. 4) relies on Col. 7, lines 8-25 in the rejection, which 
describes various entry points to the universal multipath driver. Applicant agrees that the 
presence of a filter add device function entry point 250 in the universal multipath driver implies 
"invoking the driver, which includes passing the PDO" under the construction assumed in this 
paragraph. However, this passage in Athreya etal. does not disclose, teach, or suggest 
"passing the PDO" as recited in claim 7. In fact, Athreya et al. specifically states that the filter 
add device function passes a "new filter device objecf rather than passing the physical device 
object (PDO). The Office Action (p. 4) relies on a different passage in Athreya et al. to reject the 
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"passing the PDO" feature: "driver entry 410 provides an entry point for the UMD 220 in 

response to an IRP issued by the higher level driver 218 (Col. 6, lines 60-67)". Even assuming 

(for the sake of argument) that the IRP is passed to the driver entry and that the IRP references 

a PDO, this second passage says nothing about passing the PDO, much less passing the PDO 

away from the universal multipath driver. 

Alternatively, Applicant assumes that the lower-level driver of Athreya et al. corresponds 
to the claimed "driver". The Office Action (p. 4) relies on Athreya et al. Col. 7, lines 8-25 in the 
rejection, a section describing various entry points to the universal multipath driver. This section 
appears to teach that calling the filter add device function entry point 250 in the universal 
multipath driver would in turn invoke the lower-level driver (allegedly "invoking the driver"). 
However, Athreya et al. does not disclose, teach, or suggest "passing the PDO" at all, much 
less "passing the PDO away from" the lower-level driver. In fact, Athreya et al. specifically states 
that the filter add device function passes a "new filter device object" rather than passing the 
physical device object (PDO). The Office Action (p. 4) relies on a different passage in Athreya 
et al. to reject the "passing the PDO" feature: "driver entry 410 provides an entry point for the 
UMD 220 in response to an IRP issued by the higher level driver 218 (Col. 6, lines 60-67)". 
Even assuming (for the sake of argument) that the IRP is passed to the driver entry and that the 
IRP references a PDO, this second passage says nothing about passing the PDO, much less 
passing the PDO away from the lower-level driver. 

For at least the reason that Athreya et al. fails to disclose, teach or suggest the above- 
described features, Applicant respectfully submits that Athreya era/, does not anticipate claim 7. 
Therefore, Applicant requests that the rejection of claim 7 be withdrawn. 

C. Independent Claim 13 

The Office Action contends that Athreya et al. teaches all the features of claim 1 3 as 

follows: 
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providing a multi-role driver for a plurality of device types; [universal 
multipath driver (UMD) 220; col. 6, line 55 - col. 7, line 10]; 
but not registering, in the registry of the operating system, the multi-role 
driver as having a role in assembly of the stack, [driver entry 410 provides 
an entry point for the UMD 220 in response to an IRP issued by the 
higher level driver 21 8; col. 6, lines 60 - 67]. 
(Office Action, p. 4.) 

Applicant respectfully disagrees. Athreya et al. does not discuss device driver registration at all, 
but absence of a discussion on driver registration is not the same as the specific feature recited, 
namely "not registering, in the registry of the operating system, the multi-role driver". Since 
Athreya et al. does not teach all of the features of claim 13, the rejection should be withdrawn. 

D. Dependent Claim 14 

Since independent claim 13 is allowable, Applicant respectfully submits that claim 14 is 
allowable for at least the reason that each depends from an allowable claim. In re Fine, 
837 F.2d 1071, 5 U.S.P.Q. 2d 1596, 1598 (Fed. Cir. 1988). Therefore, Applicant respectfully 
requests that the rejection of claim 14 be withdrawn. 

II. Rejection of Claims 1-5, 8-12. and 15-28 under 35 U.S.C. 51 03 

Claims 1-5, 8-12, and 15-28 are rejected under §1 03(a) as allegedly obvious over 
Athreya et al. (U.S. 7,222,348) in view of Jantz et al. (U.S. 7,093,265). Applicant respectfully 
traverses this rejection. It is well established at law that, for a proper rejection of a claim under 
35 U.S.C. §103 as being obvious based upon a combination of references, the cited 
combination of references must disclose, teach, or suggest (either implicitly or explicitly) all 
elements/features/steps of the claim at issue. See, e.g., In re Dow Chemical, 5 U.S.P.Q.2d 
1529, 1531 (Fed. Cir. 1988); In re Keller, 208 U.S.P.Q.2d 871, 881 (C.C.P.A. 1981). 

A. Independent Claim 1 

Applicant respectfully submits that claim 1 is allowable for at least the reason that the 
proposed combination of Athreya et al. in view of Jantz et al. does not disclose, teach, or 
suggest the feature of "registering a plurality of uni-role helper drivers so as to uniquely 
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correspond to the plurality of roles, respectively". In fact, neither Athreya et al. nor Jantz et al. 

discusses device driver registration at all. Since the proposed combination does not teach all of 

the features of claim 1 , the rejection should be withdrawn. 

Claim 1 is also allowable for the separate reason that the proposed combination of 
Athreya et al. in view of Jantz et al. does not disclose, teach, or suggest the feature of "indirectly 
specifying a corresponding one of the multiple roles of the multi-role driver by specifying the 
helper driver mapped thereto". The Office Action (p. 6) contends that this feature is disclosed by 
Athreya et al. as follows: "driver entry 410 provides an entry point for the UMD 220 in response 
to an IRP issued by the higher level driver 218 (col. 6, line 55 to col. 7, line 10)". Applicant 
respectfully disagrees. The Office Action (p. 5) specifically contends that the UMD in Athreya et 
al. corresponds to the claimed "multi-role driver", thus implying that the higher-level driver in 
Athreya et al. corresponds to the claimed "helper driver". Applicant assumes (for the sake of 
argument) that this correspondence is proper. Even so, the cited portion of Athreya etal. merely 
describes the invocation of the driver entry point in the UMD (alleged "multi-role driver") in 
response to an action by a higher-level driver (alleged "helper driver"). Athreya et al. does not 
describe a correspondence between roles and helper drivers as required by claim 1 . 
Furthermore, Athreya et al. describes interaction between a single higher-level driver (alleged 
"helper driver") while claim 1 refers to multiple helper drivers. 

Although not relied on by the Office Action, Applicant notes that another section of 
Athreya et al. describes a third type of driver, the lower-level driver, as follows: 

The universal multipath driver (UMD) 220 is a driver that provides 
multipath management to the storage devices shown in FIG. IB such as 
the tape drives, the tape library, and the disk subsystem. The UMD 220 
responds to an IRP sent by the higher level driver 218 and interfaces to 
the lower level driver 250. 

The lower level driver 250 includes drivers that are directly 
responsible for the control and management of the devices attached to 
the system. The lower level driver 250 includes a tape drive device driver 
252, a tape library device driver 254, and a HBA driver 256 which are 
drivers for device 165j, library 165j, and HBA 165 k , respectively. 
(Athreya et al., Col. 6, lines 25-40.) 
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This passage appears to imply that the UMD maintains some sort of association between the 

UMD itself and the lower level drivers. However, even assuming that the lower-level driver 

properly corresponds to a "helper driver", this section of Athreya et al. does not disclose (even 

implicitly) a correspondence between "roles of the multi-role driver" and helper drivers. 

Applicant notes that the Office Action appears to equate roles and physical devices (see Office 

Action, p. 6), while the language used in claim 1 refers to them as two separate items: "there 

being a multi-role driver for a plurality of roles at least one of which corresponds to the device". 

Therefore, if this rejection is maintained in a future Office Action, the Examiner is requested to 

specifically identify which feature or teaching in the references allegedly corresponds to the 

"plurality of roles" recited in claim 1. 

Finally, Jantz et al. fails to disclose, teach, or suggest "indirectly specifying a 
corresponding one of the multiple roles of the multi-role driver by specifying the helper driver 
mapped thereto". Jantz et al. does describe a type of mapping or correspondence which 
involves a driver: "the multipath driver has knowledge of the virtual-to-physical associations or 
mapping definition 132 that defines the relational correspondence between the physical paths 
and the virtual paths" (Col. 14, lines 1-5). However, even assuming (for the sake of argument) 
that the "multipath driver" of Jantz et al. can be properly substituted for the "multipath driver" of 
Athreya et al., a mapping between physical and virtual paths is not the same as a 
correspondence between roles and helper drivers as required by claim 1. 

Accordingly, the proposed combination of Athreya et al. in view of Jantz et al. does not 
teach at least the above-described features recited in claim 1. Therefore, a prima facie case 
establishing an obviousness rejection has not been made, and the rejection should be 
withdrawn. 
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B. Independent Claim 8 

Applicant respectfully submits that claim 8 is allowable for at least the reason that the 
proposed combination does not disclose, teach, or suggest the feature "providing a plurality of 
DOPush functions in a multi-role driver". The Office Action contends (p. 13) that this feature is 
disclosed at Col. 6, lines 60-67 of Athreya etal., which reads: 

FIG. 4 is a diagram illustrating the universal multipath driver (UMD) 
220 according to one embodiment of the invention. The UMD 220 
includes a driver entry 410, a major function group 420, a system thread 
480, and a path monitor 490. 

The driver entry 410 provides an entry point for the UMD 220 in 
response to an IRP issued by the higher level driver 218. The driver entry 
410 includes a driver object pointer 415 that provides address reference 
or points to the major function group 420. The driver entry 410 also 
causes creation of the system thread 480. The system thread 480 
invokes the path monitor 490. 
(Athreya et a/., Col. 6, lines 55-67.) 

Applicant respectfully disagrees. While the universal multipath driver in Athreya et al. does 
provide multiple functions, Applicant respectfully submits that none are "DOPush functions". The 
Office Action appears to have given the term used in the claim an unreasonably broad 
interpretation, and has made no attempt to explain why any of the functions in this passage in 
Athreya et al. would be interpreted by a person of ordinary skill in the art as a "DOPush 
function". Nor does Jantz et al. disclose, teach, or suggest "providing a plurality of DOPush 
functions in a multi-role driver". Accordingly, the proposed combination of Athreya etal. in view 
of Jantz et al. does not teach at least the above-described features recited in claim 8. Therefore, 
a prima facie case establishing an obviousness rejection has not been made, and the rejection 
should be withdrawn. 



C. Independent Claim 15 

Applicant respectfully submits that claim 15 is allowable for at least the reason that the 
proposed combination of Athreya et al. in view of Jantz et al. does not disclose, teach, or 
suggest the feature of "an installer code portion for registering the plurality of helper driver code 
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portions so as to uniquely map to the multiple roles, respectively". In fact, neither Athreya et al. 

nor Jantz et al. discusses device driver installation or registration at all. Since the proposed 

combination does not teach all of the features of claim 15, the rejection should be withdrawn. 

Claim 15 is also allowable for the separate reason that the proposed combination of 

Athreya et al. in view of Jantz et al. does not disclose, teach, or suggest at least the feature of 

"each helper driver code portion being operable to receive a corresponding PDO and pass the 

PDO to the multi-role driver code portion without attempting to attach to the stack a DO 

corresponding to the help driver code portion". The Office Action contends that this feature is 

disclosed by Athreya et al. as follows: 

each helper driver code portion being operable to receive a 
corresponding PDO [col. 7, lines 8-25 of Athreya] and pass the PDO to 
the multi-role driver code portion without attempting to attach to the stack 
a DO corresponding to the helper driver code portion [driver entry 410 
includes a driver object pointer 415 that provides address reference or 
points to the major function group 420; col. 6, lines 60 - 67 of Athreya]. 
(Office Action, p. 4.) 

Applicant respectfully disagrees. The second section of Athreya et al. referred to in the rejection 
reads as follows: 

FIG. 4 is a diagram illustrating the universal multipath driver (UMD) 
220 according to one embodiment of the invention. The UMD 220 
includes a driver entry 410, a major function group 420, a system thread 
480, and a path monitor 490. 

The driver entry 410 provides an entry point for the UMD 220 in 
response to an IRP issued by the higher level driver 218. The driver entry 
410 includes a driver object pointer 415 that provides address reference 
or points to the major function group 420. The driver entry 410 also 
causes creation of the system thread 480. The system thread 480 
invokes the path monitor 490. 
(Athreya et al., Col. 6, lines 55-67.) 

Even assuming (for the sake of argument) that the IRP is passed to the driver entry and that the 
IRP references a PDO, this second passage says nothing about passing the PDO. Applicant 
notes that absence of a discussion on how PDOs are passed is not the same as the specific 
feature recited in claim 15, namely "without attempting to attach to the stack a DO 
corresponding to the helper driver code portion". Also, although not relied on by the rejection, 
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Applicant notes that another section of Athreya et al. (Col. 7, lines 1 5-25) describes passing of 

device objects. However, this section specifically mentions attaching the device object to the 

stack rather than "without attempting to attach to the stack" as recited in claim 1 5. 

Finally, Jantz et al. fails to disclose, teach, or suggest "each helper driver code portion 

being operable to receive a corresponding PDO and pass the PDO to the multi-role driver code 

portion without attempting to attach to the stack a DO corresponding to the help driver code 

portion". Accordingly, the proposed combination of Athreya et al. in view of Jantz et al. does not 

teach at least the above-described features recited in claim 1 5. Therefore, a prima facie case 

establishing an obviousness rejection has not been made, and the rejection should be 

withdrawn. 

D. Independent Claim 20 

Applicant respectfully submits that claim 20 is allowable for at least the reason that the 
proposed combination of Athreya et al. in view of Jantz et al. does not disclose, teach, or 
suggest the feature of "a plurality of helper driver means registered so as to uniquely 
correspond to the plurality of roles, respectively, of the multi-role driver". In fact, neither Athreya 
et al. nor Jantz et al. discusses device driver registration at all. Since the proposed combination 
does not teach all of the features of claim 20, the rejection should be withdrawn. 

Claim 20 is also allowable for the separate reason that the proposed combination of 
Athreya et al. in view of Jantz et al. does not disclose, teach, or suggest at least the feature of 
"means for selectively invoking the multi-role driver according to one of the multiple roles via 
invoking the corresponding helper driver mapped thereto". The Office Action (p. 9) contends that 
this feature is disclosed by Athreya et al. as follows: "driver entry 410 provides an entry point for 
the UMD 220 in response to an IRP issued by the higher level driver 218 (col. 6, line 55 to 
col. 7, line 10)". Applicant respectfully disagrees. The Office Action (p. 9) specifically contends 
that the UMD in Athreya et al. corresponds to the claimed "multi-role driver", thus implying that 



18 



Serial No: 10/645,501 
HP Docket No.: 200206848-1 
TKHR Docket No.: 50850-1840 

the higher-level driver in Athreya et al. corresponds to the claimed "helper driver". Applicant 
assumes (for the sake of argument) that this correspondence is proper. Even so, the cited 
portion of Athreya et al. merely describes the invocation of the driver entry point in the UMD 
(alleged "multi-role driver") in response to an action by a higher-level driver (alleged "helper 
driver"). Athreya et al. does not describe a correspondence between roles and helper drivers as 
required by claim 20. Furthermore, Athreya et al. describes interaction between a single higher- 
level driver (alleged "helper driver") while claim 20 references multiple helper driver means. 

Although not relied on by the Office Action, Applicant notes that another section of 
Athreya et al. describes a third type of driver, the lower-level driver, as follows: 

The universal multipath driver (UMD) 220 is a driver that provides 
multipath management to the storage devices shown in FIG. 1B such as 
the tape drives, the tape library, and the disk subsystem. The UMD 220 
responds to an IRP sent by the higher level driver 218 and interfaces to 
the lower level driver 250. 

The lower level driver 250 includes drivers that are directly 
responsible for the control and management of the devices attached to 
the system. The lower level driver 250 includes a tape drive device driver 
252, a tape library device driver 254, and a HBA driver 256 which are 
drivers for device 1 65j, library 165j, and HBA 165 k , respectively. 
(Athreya et al., Col. 6, lines 25-40.) 

This passage appears to imply that the UMD maintains some sort of association between the 
UMD itself and the lower level drivers. However, even assuming that the lower-level driver 
properly corresponds to a "helper driver means", this section of Athreya et al. does not disclose 
(even implicitly) a correspondence between helper drivers and "roles" of the multi-role driver 
means. Applicant notes that the Office Action appears to equate roles and physical devices (see 
Office Action, p. 8). However, the language used in claim 20 refers to them as two separate 
items: "there being a multi-role driver for a plurality of roles at least one of which corresponds to 
the device". If this rejection is maintained in a future Office Action, the Examiner is requested to 
specifically identify which feature or teaching in the references allegedly corresponds to the 
"plurality of roles" recited in claim 20. 
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Finally, Jantz et al. fails to disclose, teach, or suggest "means for selectively invoking the 
multi-role driver according to one of the multiple roles via invoking the corresponding helper 
driver mapped thereto". Jantz et al. does describe a type of mapping or correspondence which 
involves a driver: "the multipath driver has knowledge of the virtual-to-physical associations or 
mapping definition 1 32 that defines the relational correspondence between the physical paths 
and the virtual paths" (Col. 14, lines 1-5). However, even assuming (for the sake of argument) 
that the "multipath driver" of Jantz et al. can be properly substituted for the "multipath driver" of 
Athreya et al., a mapping between physical and virtual paths is not the same as a 
correspondence between roles and helper driver means as required by claim 20. 

Accordingly, the proposed combination of Athreya et al. in view of Jantz et al. does not 
teach at least the above-described features recited in claim 20. Therefore, a prima facie case 
establishing an obviousness rejection has not been made, and the rejection should be 
withdrawn. 

E. Independent Claim 24 

Applicant respectfully submits that claim 24 is allowable for at least the reason that the 
proposed combination of Athreya et al. in view of Jantz et al. does not disclose, teach, or 
suggest the feature of "a first code portion for registering the plurality of helper driver code 
portions so as to uniquely correspond to the plurality of roles, respectively, each helper driver 
code portion mapping uniquely to one of the multiple roles of the multi-role driver, respectively". 
In fact, neither Athreya et al. nor Jantz et al. discusses device driver registration at all. Since the 
proposed combination does not teach all of the features of claim 24, the rejection should be 
withdrawn. 

Claim 24 is also allowable for the separate reason that the proposed combination of 
Athreya et al. in view of Jantz et al. does not disclose, teach, or suggest the feature of "a second 
code portion for indirectly specifying a corresponding one of the multiple roles of the multi-role 
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driver by specifying the helper driver code portion mapped thereto". The Office Action (p. 9) 

contends that this feature is disclosed by Athreya et al. as follows: "driver entry 410 provides an 

entry point for the UMD 220 in response to an IRP issued by the higher level driver 218 (col. 6, 

line 55 to col. 7, line 10)". Applicant respectfully disagrees. The Office Action (p. 8) specifically 

contends that the UMD in Athreya et al. corresponds to the claimed "multi-role driver", thus 

implying that the higher-level driver in Athreya et al. corresponds to the claimed "helper driver". 

Applicant assumes (for the sake of argument) that this correspondence is proper. Even so, the 

cited portion of Athreya et al. merely describes the invocation of the driver entry point in the 

UMD (alleged "multi-role driver") in response to an action by a higher-level driver (alleged 

"helper driver"). Athreya et al. does not describe a correspondence between roles and helper 

drivers as required by claim 24. Furthermore, Athreya et al. describes interaction between a 

single higher-level driver (alleged "helper driver") while claim 24 refers to multiple helper 

drivers. 

Although not relied on by the Office Action, Applicant notes that another section of 
Athreya et al. describes a third type of driver, the lower-level driver, as follows: 

The universal multipath driver (UMD) 220 is a driver that provides 
multipath management to the storage devices shown in FIG. 1B such as 
the tape drives, the tape library, and the disk subsystem. The UMD 220 
responds to an IRP sent by the higher level driver 218 and interfaces to 
the lower level driver 250. 

The lower level driver 250 includes drivers that are directly 
responsible for the control and management of the devices attached to 
the system. The lower level driver 250 includes a tape drive device driver 
252, a tape library device driver 254, and a HBA driver 256 which are 
drivers for device 165j, library 165j, and HBA 165 k , respectively. 
(Athreya et al., Col. 6, lines 25-40.) 

This passage appears to imply that the UMD maintains some sort of association between the 
UMD itself and the lower level drivers. However, even assuming that the lower-level driver 
properly corresponds to a "helper driver", this section of Athreya et al. does not disclose (even 
implicitly) a correspondence between "roles of the multi-role driver" and helper drivers. 
Applicant notes that the Office Action appears to equate roles and physical devices (see Office 
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Action, p. 6), while the language used in claim 24 refers to them as two separate items: "there 

being a multi-role driver for a plurality of roles at least one of which corresponds to the device". 

Therefore, if this rejection is maintained in a future Office Action, the Examiner is requested to 

specifically identify which feature or teaching in the references allegedly corresponds to the 

"plurality of roles" recited in claim 24. 

Finally, Jantz et al. fails to disclose, teach, or suggest "indirectly specifying a 
corresponding one of the multiple roles of the multi-role driver by specifying the helper driver 
mapped thereto". Jantz et al. does describe a type of mapping or correspondence which 
involves a driver: "the multipath driver has knowledge of the virtual-to-physical associations or 
mapping definition 132 that defines the relational correspondence between the physical paths 
and the virtual paths" (Col. 14, lines 1-5). However, even assuming (for the sake of argument) 
that the "multipath driver" of Jantz et al. can be properly substituted for the "multipath driver" of 
Athreya et al., a mapping between physical and virtual paths is not the same as a 
correspondence between roles and helper drivers as required by claim 24. 

Accordingly, the proposed combination of Athreya et al. in view of Jantz et al. does not 
teach at least the above-described features recited in claim 24. Therefore, a prima facie case 
establishing an obviousness rejection has not been made, and the rejection should be 
withdrawn. 

F. Dependent Claims 2-5, 9-12, 16-19, 21-23, and 25-28 

Since independent claims 1,8, 15, 20, and 24 are allowable, Applicant respectfully 
submits that claims 2-5, 9-12, 16-19, 21-23, and 25-28 are allowable for at least the reason that 
each depends from an allowable claim. In re Fine, 837 F.2d 1071, 5 U.S.P.Q. 2d 1596, 1598 
(Fed. Cir. 1988). Therefore, Applicant respectfully requests that the rejection of claims 2-5, 9-12, 
16-19, 21-23, and 25-28 be withdrawn. 
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CONCLUSION 

Applicant respectfully requests that all outstanding objections and rejections be 
withdrawn and that this application and presently pending claims 1-28 be allowed to issue. Any 
statements in the Office Action that are not explicitly addressed herein are not intended to be 
admitted. In addition, any and all findings of inherency are traversed as not having been shown 
to be necessarily present. Furthermore, any and all findings of well-known art and official notice, 
or statements interpreted similarly, should not be considered well known since the Office Action 
does not include specific factual findings predicated on sound technical and scientific reasoning 
to support such conclusions. If the Examiner has any questions or comments regarding 
Applicant's response, the Examiner is encouraged to telephone Applicant's undersigned 
counsel. 



Respectfully submitted, 

By: /Karen G. Hazzah/ 

Karen G. Hazzah, Reg. No. 48,472 

Thomas, Kayden, Horstemeyer 
& Risley, L.L.P. 

600 Galleria Parkway, SE 
Suite 1500 

Atlanta, Georgia 30339 
Tel: (770)933-9500 
Fax: (770) 951-0933 
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